Refactor feature flags to use functional availability rules - #3166

s.mu is held across the s.checker(ctx, feature) call, which makes this non-reentrant: a checker that consults another flag (via ResolveFeature or deps.IsFeatureEnabled) on the same context deadlocks the request. Not an error — a hard hang. I reproduced it with a probe test against this branch:

checker := func(c context.Context, flag FeatureFlag) (bool, error) {
	if flag == "meta" {
		return ResolveFeature(c, nil, "base"), nil
	}
	return true, nil
}
ctx := WithResolvedFeatures(context.Background(), checker, nil)
ResolveFeature(ctx, nil, "meta") // never returns

The same lock also serializes every flag lookup for the request, which matters if the remote server's checker does I/O. Could we resolve outside the lock (double-check on insert) or use a per-flag sync.Once/singleflight?

The checker argument is silently ignored whenever context state already exists, which has two consequences worth pinning down:

1. BaseDeps/RequestDeps pass their own featureChecker, but the inventory's checker wins if it installed state first. A consumer wiring different checkers for inventory vs. deps gets whichever ran first, with no signal.
2. Behavior change: IsFeatureEnabled with a nil deps checker previously always returned false. It now returns the inventory-resolved value. The doc comment on BaseDeps.IsFeatureEnabled still says "Returns false if the feature checker is nil", so at minimum that's stale.

Either drop the parameter and make context state authoritative, or document the precedence explicitly here.

Undeclared-flag detection only fires if the predicate actually evaluates that branch. Because predicates short-circuit, a rule that reads an undeclared flag in a rarely-taken branch works fine until it doesn't, and then silently drops the tool from the surface with one line on stderr — hard to spot in production.

Declared sets here are 1–2 flags, so NewFeatureRule could probe the predicate over all 2^n combinations at construction time and fail loudly on an undeclared read. Failing that, a package-level guard test over the real inventory would catch it at CI time rather than at request time.

This walk gets repeated several times per request: handler.ServeHTTP calls WithResolvedFeatures (→ RequiredFeatures + usesMCPAppsMetadata), then ToolsForRegistration runs both again, then AvailableTools runs requiredToolFeatures a third time. Each pass allocates a rule slice plus a dedup map over the whole inventory.

Since tools/resources/prompts are fixed after Build() (and after ForMCPRequest narrowing), could the required-feature set and the usesMCPAppsMetadata bool be computed once and stored on Inventory?

This resolves and caches the flag values before the MCP receiving middlewares run (injectFeatureStateMiddleware, InjectDepsMiddleware). Fine for this repo's header-based checker, but a checker that reads actor/session data populated later in the chain would see a thinner context here, and the resulting value then sticks for the rest of the request.

The RegisterTools doc comment already warns about exactly this class of bug ("HTTP feature checkers that read insiders mode or user identity from ctx would otherwise see context.Background()"). Worth confirming against the remote server's checker before this lands — if it needs the enriched context, the resolution point should move after the middlewares.